This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (April 2010)

The grave accent ( ` ) ( /ˈɡreɪv/ or UK /ˈɡrɑːv/)^[1] is a diacritical mark used in written Breton, Catalan, Corsican, Dutch, French, Greek (until 1982; see polytonic orthography), Italian, Macedonian, Mohawk, Norwegian, Occitan, Portuguese, Ligurian, Scottish Gaelic, Vietnamese, Welsh, Romansh, and other languages.

Uses[link]

Pitch[link]

Greek[link]

The grave accent was first used in the polytonic orthography of Ancient Greek to mark a lower pitch than the high pitch of the acute accent. In modern practice, it is used to replace an acute accent in the last syllable of a word when the word is followed immediately by another word in the sentence.

Originally, however, the grave marked any syllable that was not marked with an acute or circumflex.^[2] This practice was soon given up for the less laborious one of marking only the last syllable.

Since Modern Greek has a stress accent instead of a pitch accent, both the grave and circumflex have been replaced with an acute accent in the modern monotonic orthography.

Stress[link]

The grave accent marks the stressed vowel of a word in Catalan and Italian.

General rule is that in Italian words ending with stressed -a, -i, -o, -u must be marked with a grave accent. So only words ending with stressed -e may bear both an acute accent or a grave accent (closed 'e' sound vs. open 'e' sound). Some examples are: città "city", morì "[he/she] died", virtù "virtue", Mosè "Moses", portò "[he/she/it] brought, carried". Especially with capital letters, or when using a keyboard without accented letters, an apostrophe is sometimes used instead of the proper accent, thus E’ instead of È "[he/she/it] is", though it is technically an error. Other mistakes arise from the misunderstanding of truncated and elided words: for example the phrase un po’, meaning "a little", which is the truncated version of un poco, is infrequently spelt as un pò. In Italian there are many pairs of words, one with an accent marked and the other not, with different pronunciation and meaning, such as pero "pear tree" and però "but", and Papa "Pope" and papà "dad" (the last example is also valid for Catalan).

In Bulgarian and Macedonian, the grave is used on the vowels а, о, у, е, и, ъ (Bulgarian only), to mark stress. It is particularly used in books for children or foreigners, or to distinguish between near-homophones: па̀ра steam, vapour and пара̀ cent/penny, money, въ̀лна wool and вълна̀ wave. In a few cases (mostly on the vowels е and и) the stress mark is orthographically required to distinguish words which are homonyms. For example, the Macedonian negation particle не is a homonym with the short-form of the direct object personal pronoun нe – thus нѐ. The grave in these cases forces the stress on the graved word-syllable, instead of having a different syllable in the stress group get accented. In turn, this changes the pronunciation and the whole meaning of the group.

In Ukrainian, Rusyn, Belarusian and Russian, the similar system was in use until the first half of the 20th century. Now the main stress is preferably being marked with an acute, and the role of grave is limited to mark secondary stress in compound words (in dictionaries and in linguistic literature).

In the descendants of Serbo-Croatian and in Slovene, the stressed syllabe can be short or long, as well as having rising or falling tone. To show this, these languages use (in dictionaries, orthography and grammar books etc.) four different stress marks (grave, acute, double grave and circumflex). The system is identical both in Latin and Cyrillic scripts.

In modern Church Slavonic, there are three stress marks (acute, grave and circumflex). There is no phonetical distinction between them, only the orthographical one. Grave is typically used when the stressed vowel is the last letter of a multi-letter word.

In Ligurian, the grave accent marks the accented short vowel of a word in à (sound [a]), è (sound [ɛ]), ì (sound [i]) and ù (sound [y]). In the case of ò, it is used for the short sound of [O], but it may not be the stressed vowel of the word.

Height[link]

The grave accent marks the height or openness of the vowels e and o, indicating that they are pronounced open: è [ɛ] (as opposed to é [e]); ò [ɔ] (as opposed to ó [o]), in several Roman languages:

• Catalan uses the accent on three letters (a, e, and o).
• French uses the accent on three letters (a, e, and u), but only with e does it serve to indicate a pronunciation change. For example, the accent mark in lève [lεv], indicates that it is not pronounced as a schwa, like in lever [ləve].
• Italian
• Occitan
• Ligurian, which also uses the grave accent to distinguish the sound [O] (written ò) from the sound [u], written ó.

Disambiguation[link]

The grave accent is used to distinguish homophones in several languages:

• Catalan, where it distinguishes, for example, ma ("my") from mà ("hand").
• French. The grave accent on the letters a and u has no effect on pronunciation and only serves to distinguish homonyms that are otherwise spelled the same. It distinguishes the preposition à ("to/belonging to/towards") from the verb a (the third-person singular present tense of avoir), as well as the adverb là ("there") and the feminine definite article la; it is also used in the word déjà and the phrase çà et là ("hither and thither"; without the accent, it would literally mean "it and the"). It is used on the letter u only to distinguish où ("where") and ou ("or"). È is rarely used to distinguish homonyms, except in dès/des ("since/some"), ès/es ("in/are"), and lès/les ("near/the").
• Italian, where it distinguishes for example the conjunction e "and" from the verb è ("he/she/it is"), or the feminine article la from the adverb là ("there").
• In Norwegian (both Bokmål and Nynorsk), the grave accent is used to separate words which would otherwise be identical, for instance og (and) and òg (too). Popular usage, possibly because Norwegian rarely uses diacritics, often leads to a grave accent being used in place of an acute accent.
• Romansh, where it distinguishes (in the "Rumantsch Grischun" standard) e "and" from the verb form è ("he/she/it is") and en "in" from èn ("they are"). The grave also marks distinctions of stress (gia "already" vs. gìa "violin") and of vowel quality (letg "bed" vs. lètg "marriage").

Length[link]

In Welsh, the accent is used to denote a short vowel sound in a word which would otherwise be pronounced with a long vowel sound, for example mẁg [mʊɡ] "mug" versus mwg [muːɡ] "smoke".

In Scottish Gaelic, it denotes a long vowel – the use of acute accents is seen in older texts, but is no longer allowed according to the new orthographical conventions.

Tone[link]

In some tonal languages such as Vietnamese and Mandarin Chinese (when written in Hanyu Pinyin or Zhuyin Fuhao), the grave accent is used to indicate a falling tone. The alternative to the grave accent in Mandarin is the numeral 4 after the syllable: pà = pa4.

In African languages, the grave accent is often used to indicate a low tone, e.g. Nobiin jàkkàr "fish-hook", Yoruba àgbọ̀n "chin", Hausa màcè "woman".

The grave accent is used to represent the low tone in Kanien'kéha or Mohawk.

Other uses[link]

In Portuguese, the grave accent indicates the contraction of two consecutive vowels in adjacent words (crasis). For example, instead of a aquela hora ("at that hour"), one says and writes àquela hora.

In Hawaiian, the grave accent (alone, not placed over another character) is sometimes encountered as a typographically easier substitute for the ʻokina, e.g. Hawai`i instead of Hawaiʻi.

English[link]

The grave accent, although not standardly applied to any English words, is sometimes used in poetry and song lyrics to indicate that a vowel usually silent is to be pronounced, in order to fit the rhythm or meter. Most often, it is applied to a word ending with -ed. For instance, the word looked is usually pronounced /ˈlʊkt/ as a single syllable, with the e silent; when written as lookèd, the e is pronounced: /ˈlʊk.ɨd/ look-ed). It can also be used in this capacity to distinguish certain pairs of identically spelled words like the past tense of learn, learned /ˈlɜrnd/, from the adjective learnèd /ˈlɜrn.ɨd/ (for example, "a very learnèd man").

Italics, with appropriate accents, are generally applied to foreign terms that are uncommonly used in or have not been assimilated into English: for example, vis-à-vis, pièce de résistance and crème brûlée.

[edit] Technical notes

The ISO-8859-1 character encoding includes the letters à, è, ì, ò, ù, and their respective capital forms. Dozens more letters with the grave accent are available in Unicode.

In the ASCII character set the grave accent is encoded as character 96, hex 60. Unicode also provides the grave accent as a combining character, encoded as 768, hex 300. Outside the US, character 96 is often replaced by accented letters. In the French ISO 646 standard, the character at this position is µ. Many older UK computers, such as the ZX Spectrum and BBC Micro, have the £ symbol as character 96, though the British ISO 646 variant ultimately placed this symbol at position 35 instead.

On many computer keyboards, the grave accent occupies a key by itself, and is meant to be combined with vowels as a multi-key combination or as a dead key to modify the following letter.

On a Mac, to get a character such as à, the user must type Option-` and then the vowel. For example, to make à, the user must type Option-` and then 'a', and to make À, the user must type Option-` and then Shift-a.

On a system running the X Window System, to get a character such as à, the user should press compose and ` together, then the vowel. The compose key on modern keyboards is usually mapped to a Windows key or shift+AltGR.^[3]

On a US and UK QWERTY keyboard, the grave accent key is placed in the top left corner. In many PC based computer games, the key is used to open the console window, allowing the user to execute commands via a CLI.

Use in programming[link]

Programmers have used the grave accent symbol by itself (i.e. not combined with some letter) for a number of tasks. In this role, it is known as a backquote or backtick.

When using TeX to typeset text, the backtick character is used as a syntax to represent curly opening quotes. For example, ` is rendered as single opening curly quote (‘) and `` is a double curly opening quote (“). It is also used for using the numeric ASCII value of an ASCII character wherever a number is expected.

Many of the Unix shells and the programming languages Perl, PHP, and Ruby use pairs of this character to indicate command substitution, that is, substitution of the standard output from one command into a line of text defining another command. For example, the code line:

echo It is now `date` 

might result, after command substitution, in the command:

echo It is now Tue Jun 26 16:38:04 GMT 2012

which then on execution produces the output:

It is now Tue Jun 26 16:38:04 GMT 2012

In the Bash shell, the `...` is deprecated in favour of $(...).^[4] The same is true of Z shell.^[5]

In Lisp macro systems, the backquote character (called quasiquote in Scheme) introduces a quoted expression in which comma-substitution may occur. It is identical to the plain quote, except that symbols prefixed with a comma will be replaced with those symbols' values as variables. This is roughly analogous to the Unix shell's variable interpolation with $ inside double quotes.

In m4, it is used together with an apostrophe to quote strings (to suppress or defer macro expansion).

In MySQL, it is used in queries as a table and database classifier.

In Pico, the backquote is used to indicate comments in the programming language.

In Haskell, a function name surrounded by backquote allows you to use it as an infix operator.

In OCaml, the backquote is used to indicate polymorphic variants.

In Tom_(pattern_matching_language)Tom, the backquote is used to create a new term or to call an existing term.

In Go, the backquote is used to surround a raw string literal.

Windows PowerShell uses the backquote as the escape character. For example, a newline character is denoted `n. Most commonly used programming languages use a backslash as the escape character (e.g. \n) but because Windows allows the backslash as a path separator, it would have been impractical for PowerShell to use backslash for a different purpose. To get the ` character itself, use two backticks. For example the nullable boolean of .NET is specified in PowerShell as [Nullable``1[System.Boolean]].

Prior to Python 3.0, backticks were used as a synonym for the repr() function, which converts its argument to a string suitable for a programmer to view. However, this feature was removed in Python 3.0. Backticks are also used extensively in the reStructuredText plain text markup language (implemented in the Python docutils package).

In Verilog, the grave accent is used to define constants (e.g. after the line `define NUM 100, `NUM can be used as a synonym for 100) whereas the apostrophe is used in specifying sized constants (for example, 5'd10 is a 5-bit constant with the value 10). Accidental use of an apostrophe instead of a grave accent and vice versa is a source of frequent beginner mistakes in the language.

In Unlambda, the backquote character denotes function application.

In BBC BASIC, the backquote character is valid within (and at the beginning of) a variable, structure, procedure or function name.

See also[link]

• Acute accent
• Circumflex
• Double grave accent

References[link]

External links[link]

• Diacritics Project – All you need to design a font with correct accents
• ASCII and Unicode quotation marks – "Please do not use the ASCII grave accent as a left quotation mark"
• Keyboard Help – Learn how to create world language accent marks and other diacriticals on a computer

Look up à or è in Wiktionary, the free dictionary.

This article contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity or Wikibooks. (July 2011)

Text file created with gedit and viewed with a hex editor
Besides the text objects there are only EOL markers
with the hexadecimal value 0A.

In computing, a newline,^[1] also known as a line break or end-of-line (EOL) marker, is a special character or sequence of characters signifying the end of a line of text. The name comes from the fact that the next character after the newline will appear on a new line—that is, on the next line below the text immediately preceding the newline. The actual codes representing a newline vary across operating systems, which can be a problem when exchanging text files between systems with different newline representations.

There is also some confusion whether newlines terminate or separate lines. If a newline is considered a separator, there will be no newline after the last line of a file. The general convention on most systems is to add a newline even after the last line, i.e. to treat newline as a line terminator. Some programs have problems processing the last line of a file if it is not newline terminated. Conversely, programs that expect newline to be used as a separator will interpret a final newline as starting a new (empty) line.

In text intended primarily to be read by humans using software which implements the word wrap feature, a newline character typically only needs to be stored if a line break is required independent of whether the next word would fit on the same line, such as between paragraphs and in vertical lists. See hard return and soft return.

Representations[link]

Software applications and operating systems usually represent a newline with one or two control characters:

• Systems based on ASCII or a compatible character set use either LF (Line feed, '\n', 0x0A, 10 in decimal) or CR (Carriage return, '\r', 0x0D, 13 in decimal) individually, or CR followed by LF (CR+LF, '\r\n', 0x0D0A). These characters are based on printer commands: The line feed indicated that one line of paper should feed out of the printer thus instructed the printer to advance the paper one line, and a carriage return indicated that the printer carriage should return to the beginning of the current line. Some rare systems, such as QNX before version 4, used the ASCII RS (record separator, 0x1E, 30 in decimal) character as the newline character.
  • LF:    Multics, Unix and Unix-like systems (GNU/Linux, Mac OS X, FreeBSD, AIX, Xenix, etc.), BeOS, Amiga, RISC OS and others.
  • CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC-DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS
  • LF+CR: Acorn BBC and RISC OS spooled text output.
  • CR:    Commodore 8-bit machines, Acorn BBC, TRS-80, Apple II family, Mac OS up to version 9 and OS-9
  • RS:    QNX pre-POSIX implementation.
• EBCDIC systems—mainly IBM mainframe systems, including z/OS (OS/390) and i5/OS (OS/400)—use NEL (Next Line, 0x15) as the newline character. Note that EBCDIC also has control characters called CR and LF, but the numerical value of LF (0x25) differs from the one used by ASCII (0x0A). Additionally, there are some EBCDIC variants that also use NEL but assign a different numeric code to the character.
• Operating systems for the CDC 6000 series defined a newline as two or more zero-valued six-bit characters at the end of a 60-bit word. Some configurations also defined a zero-valued character as a colon character, with the result that multiple colons could be interpreted as a newline depending on position.
• ZX80 and ZX81, home computers from Sinclair Research Ltd used a specific non-ASCII character set with code NEWLINE (0x76, 118 decimal) as the newline character.
• OpenVMS uses a record-based file system, which stores text files as one record per line. In most file formats, no line terminators are actually stored, but the Record Management Services facility can transparently add a terminator to each line when it is retrieved by an application. The records themselves could contain the same line terminator characters, which could either be considered a feature or a nuisance depending on the application.
• Fixed line length was used by some early mainframe operating systems. In such a system, an implicit end-of-line was assumed every 80 characters, for example. No newline character was stored. If a file was imported from the outside world, lines shorter than the line length had to be padded with spaces, while lines longer than the line length had to be truncated. This mimicked the use of punched cards, on which each line was stored on a separate card, usually with 80 columns on each card. Many of these systems added an carriage control character to the start of the next record, this could indicate if the next record was a continuation of the line started by the previous record, or a new line, or should overprint the previous line (similar to a CR). Often this was a normal printing character such as '#' that thus could not be used as the first character in a line. Some early line printers interpreted these characters directly in the records sent to them.

Most textual Internet protocols (including HTTP, SMTP, FTP, IRC and many others) mandate the use of ASCII CR+LF (0x0D 0x0A) on the protocol level, but recommend that tolerant applications recognize lone LF as well. In practice, there are many applications that erroneously use the C newline character '\n' instead (see section Newline in programming languages below). This leads to problems when trying to communicate with systems adhering to a stricter interpretation of the standards; one such system is the qmail MTA that actively refuses to accept messages from systems that send bare LF instead of the required CR+LF.^[2]

FTP has a feature to transform newlines between CR+LF and LF only when transferring text files. This must not be used on binary files. Usually binary files and text files are recognised by checking their filename extension.

Unicode[link]

The Unicode standard defines a large number of characters that conforming applications should recognize as line terminators:^[3]

 LF:    Line Feed, U+000A
 VT:    Vertical Tab, U+000B
 FF:    Form Feed, U+000C
 CR:    Carriage Return, U+000D
 CR+LF: CR (U+000D) followed by LF (U+000A)
 NEL:   Next Line, U+0085
 LS:    Line Separator, U+2028
 PS:    Paragraph Separator, U+2029

This may seem overly complicated compared to an approach such as converting all line terminators to a single character, for example LF. However, Unicode was designed to preserve all information when converting a text file from any existing encoding to Unicode and back. Therefore, Unicode should contain characters included in existing encodings. NEL is included in ISO-8859-1^{[citation needed]} and EBCDIC (0x15). The approach taken in the Unicode standard allows round-trip transformation to be information-preserving while still enabling applications to recognize all possible types of line terminators.

Recognizing and using the newline codes greater than 0x7F is not often done. They are multiple bytes in UTF-8 and the code for NEL has been used as the ellipsis ('…') character in Windows-1252. For instance:

• YAML^[4] no longer recognizes them as special in order to be compatible with JSON.
• ECMAScript^[5] accepts LS and PS as line breaks, but considers U+0085 (NEL) white space, not a line break.
• Microsoft Windows 2000 does not treat any of NEL, LS or PS as line-break in the default text editor Notepad
• In Linux, a popular editor "gedit" treats LS and PS as newlines but does not for NEL.

History[link]

ASCII was developed simultaneously by the ISO and the ASA, the predecessor organization to ANSI. During the period of 1963–1968, the ISO draft standards supported the use of either CR+LF or LF alone as a newline, while the ASA drafts supported only CR+LF.

The sequence CR+LF was in common use on many early computer systems that had adopted Teletype machines, typically a Teletype Model 33 ASR, as a console device, because this sequence was required to position those printers at the start of a new line. On these systems, text was often routinely composed to be compatible with these printers, since the concept of device drivers hiding such hardware details from the application was not yet well developed; applications had to talk directly to the Teletype machine and follow its conventions.

Most minicomputer systems from DEC used this convention. CP/M used it as well, to print on the same terminals that minicomputers used. From there MS-DOS (1981) adopted CP/M's CR+LF in order to be compatible, and this convention was inherited by Microsoft's later Windows operating system.

The separation of the two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in one-character time. That is why the sequence was always sent with the CR first. In fact, it was often necessary to send extra characters (extraneous CRs or NULs, which are ignored) to give the print head time to move to the left margin. Even many early video displays required multiple character times to scroll the display.

The Multics operating system began development in 1964 and used LF alone as its newline. Multics used a device driver to translate this character to whatever sequence a printer needed (including extra padding characters), and the single byte was much more convenient for programming. The seemingly more obvious choice of CR was not used, as a plain CR provided the useful function of overprinting one line with another, and thus it was useful to not translate it. Unix followed the Multics practice, and later systems followed Unix.

In programming languages[link]

To facilitate the creation of portable programs, programming languages provide some abstractions to deal with the different types of newline sequences used in different environments.

The C programming language provides the escape sequences '\n' (newline) and '\r' (carriage return). However, these are not required to be equivalent to the ASCII LF and CR control characters. The C standard only guarantees two things:

1. Each of these escape sequences maps to a unique implementation-defined number that can be stored in a single char value.
2. When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, no translation is performed, and the internal representation produced by '\n' is output directly.

On Unix platforms, where C originated, the native newline sequence is ASCII LF (0x0A), so '\n' was simply defined to be that value. With the internal and external representation being identical, the translation performed in text mode is a no-op, and text mode and binary mode behave the same. This has caused many programmers who developed their software on Unix systems simply to ignore the distinction completely, resulting in code that is not portable to different platforms.

The C library function fgets() is best avoided in binary mode because any file not written with the UNIX newline convention will be misread. Also, in text mode, any file not written with the system's native newline sequence (such as a file created on a UNIX system, then copied to a Windows system) will be misread as well.

Another common problem is the use of '\n' when communicating using an Internet protocol that mandates the use of ASCII CR+LF for ending lines. Writing '\n' to a text mode stream works correctly on Windows systems, but produces only LF on Unix, and something completely different on more exotic systems. Using "\r\n" in binary mode is slightly better.

Many languages, such as C++, Perl,^[6] and Haskell provide the same interpretation of '\n' as C.

Java, PHP,^[7] and Python^[8] provide the '\r\n' sequence (for ASCII CR+LF). In contrast to C, these are guaranteed to represent the values U+000A and U+000D, respectively.

The Java I/O libraries do not transparently translate these into platform-dependent newline sequences on input or output. Instead, they provide functions for writing a full line that automatically add the native newline sequence, and functions for reading lines that accept any of CR, LF, or CR+LF as a line terminator (see BufferedReader.readLine()). The System.getProperty() method can be used to retrieve the underlying line separator.

Example:

  String eol = System.getProperty( "line.separator" );
  String lineColor = "Color: Red" + eol;

Python permits "Universal Newline Support" when opening a file for reading, when importing modules, and when executing a file.^[9]

Some languages have created special variables, constants, and subroutines to facilitate newlines during program execution.

Common problems[link]

The different newline conventions often cause text files that have been transferred between systems of different types to be displayed incorrectly. For example, files originating on Unix or Apple Macintosh systems may appear as a single long line on some Windows programs. Conversely, when viewing a file originating from a Windows computer on a Unix system, the extra CR may be displayed as ^M at the end of each line or as a second line break.

The problem can be hard to spot if some programs handle the foreign newlines properly while others do not. For example, a compiler may fail with obscure syntax errors even though the source file looks correct when displayed on the console or in an editor. On a Unix system, the command cat -v myfile.txt will send the file to stdout (normally the terminal) and make the ^M visible, which can be useful for debugging. Modern text editors generally recognize all flavours of CR / LF newlines and allow the user to convert between the different standards. Web browsers are usually also capable of displaying text files and websites which use different types of newlines.

The File Transfer Protocol can automatically convert newlines in files being transferred between systems with different newline representations when the transfer is done in "ASCII mode". However, transferring binary files in this mode usually has disastrous results: Any occurrence of the newline byte sequence—which does not have line terminator semantics in this context, but is just part of a normal sequence of bytes—will be translated to whatever newline representation the other system uses, effectively corrupting the file. FTP clients often employ some heuristics (for example, inspection of filename extensions) to automatically select either binary or ASCII mode, but in the end it is up to the user to make sure his or her files are transferred in the correct mode. If there is any doubt as to the correct mode, binary mode should be used, as then no files will be altered by FTP, though they may display incorrectly.

Conversion utilities[link]

This article contains instructions, advice, or how-to content. The purpose of Wikipedia is to present facts, not to train. Please help improve this article either by rewriting the how-to content or by moving it to Wikiversity or Wikibooks. (June 2010)

Text editors are often used for converting a text file between different newline formats; most modern editors can read and write files using at least the different ASCII CR/LF conventions. The standard Windows editor Notepad is not one of them (although Wordpad and the MS-DOS Editor are).

Editors are often unsuitable for converting larger files. For larger files (on Windows NT/2000/XP) the following command is often used:

TYPE unix_file | FIND "" /V > dos_file

On many Unix systems, the dos2unix (sometimes named fromdos or d2u) and unix2dos (sometimes named todos or u2d) utilities are used to translate between ASCII CR+LF (DOS/Windows) and LF (Unix) newlines. Different versions of these commands vary slightly in their syntax. However, the tr command is available on virtually every Unix-like system and is used to perform arbitrary replacement operations on single characters. A DOS/Windows text file can be converted to Unix format by simply removing all ASCII CR characters with

tr -d '\r' < inputfile > outputfile

or, if the text has only CR newlines, by converting all CR newlines to LF with

tr '\r' '\n' < inputfile > outputfile

The same tasks are sometimes performed with awk, sed, Tr_(Unix) or in Perl if the platform has a Perl interpreter:

awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile  # UNIX to DOS  (adding CRs on Linux and BSD based OS that haven't GNU extensions)
awk '{gsub("\r",""); print;}' inputfile > outputfile              # DOS to UNIX  (removing CRs on Linux and BSD based OS that haven't GNU extensions)
sed -e 's/$/\r/' inputfile > outputfile              # UNIX to DOS  (adding CRs on Linux based OS that use GNU extensions)
sed -e 's/\r$//' inputfile > outputfile              # DOS  to UNIX (removing CRs on Linux based OS that use GNU extensions)
cat inputfile | tr -d "\r" > outputfile              # DOS  to UNIX (removing CRs using tr(1). Not Unicode compliant.)
perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile  # Convert to DOS
perl -pe 's/\r?\n|\r/\n/g'   inputfile > outputfile  # Convert to UNIX
perl -pe 's/\r?\n|\r/\r/g'   inputfile > outputfile  # Convert to old Mac

To identify what type of line breaks a text file contains, the file command can be used. Moreover, the editor Vim can be convenient to make a file compatible with the Windows notepad text editor. For example:

[prompt] > file myfile.txt
myfile.txt: ASCII English text
[prompt] > vim myfile.txt
  within vim :set fileformat=dos
             :wq
[prompt] > file myfile.txt
myfile.txt: ASCII English text, with CRLF line terminators

The following grep commands echo the filename (in this case myfile.txt) to the command line if the file is of the specified style:

grep -PL $'\r\n' myfile.txt # show UNIX style file (LF terminated)
grep -Pl $'\r\n' myfile.txt # show DOS style file (CRLF terminated)

For Debian-based systems, these commands are used:

egrep -L $'\r\n' myfile.txt # show UNIX style file (LF terminated)
egrep -l $'\r\n' myfile.txt # show DOS style file (CRLF terminated)

The above grep commands work under Unix systems or in Cygwin under Windows. Note that these commands make some assumptions about the kinds of files that exist on the system (specifically it's assuming only UNIX and DOS-style files—no Mac OS 9-style files).

This technique is often combined with find to list files recursively. For instance, the following command checks all "regular files" (e.g. it will exclude directories, symbolic links, etc.) to find all UNIX-style files in a directory tree, starting from the current directory (.), and saves the results in file unix_files.txt, overwriting it if the file already exists:

find . -type f -exec grep -PL '\r\n' {} \; > unix_files.txt

This example will find C files and convert them to LF style line endings:

find -name '*.[ch]' -exec fromdos {} \;

The file command also detects the type of EOL used:

file myfile.txt
> myfile.txt: ASCII text, with CRLF line terminators

Other tools permit the user to visualise the EOL characters:

od -a myfile.txt
cat -e myfile.txt
hexdump -c myfile.txt

dos2unix, unix2dos, mac2unix, unix2mac, mac2dos, dos2mac can perform conversions. The flip^[10] command is often used.

See also[link]

• ASA carriage control characters
• C0 and C1 control codes
• Page break
• Line starve

References[link]

External links[link]

• The Unicode reference, see paragraph 5.8 in Chapter 5 of the Unicode 4.0 standard (PDF)
• "The End-of-Line Story"
• The [NEL] Newline Character
• The End of Line Puzzle
• Tofrodos - software for Unix that converts to and from DOS newlines
• ToFroWin: a Windows shell extension that is able to convert multiple files from DOS to UNIX (and vice-versa) line endings right from the context menu.
• "Understanding Newlines" on O'Reilly-Net - an article by Xavier Noria.